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ABSTRACT 


The preliminary specification of a systems implementation language, 
called BLISS-360, is given. BLISS-360 is intended to be used for genera- 
tion of software for the IBM S/360 computer, and is patterned after 
BLISS-10 which was originally designed for the PDP-10. The Backus- 

Naur Form description of BLISS-360 is given in a form acceptable to the 
Mixed-Strategy Precedence parser of the XPL Compiler Generator System. 
Thus, the XPL System can be used to aid future developmental efforts leading 


to a completed compiler for BLISS-360. 
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PRODUCTION 


What is BLISS? Why is it important? These are some of the 
questions that must be answered in order to obtain an understanding of 
this new concept in programming languages. The following sections 
present details regarding its creation, design, and implementation in 


order to answer these questions. 


jae BACKGROUND 
This section provides the historical background of the language 
BLISS, the factors used as guidelines in its design, and a description 
of the language. 
1G Historical Background 
A ——- project on computer networks resulted in the ac- 
quisition of a PDP-10 computer at Carnegie-Mellon University in 1969. 
Part of this project consisted of producing a substantial number of large 
systems programs traditionally written in assembly language. Due to the 
inherent problems in the production and Pemrenanes of such programs, 
members of the Computer Science Department staff (Wulf, Russell, and 
Habermann [Ref.1]) considered the use of a higher level language. 
Because of the numerous types of languages available, the 
question of which to select was not an easy One to answer. For example, 


there are many languages in existence which are specifically designed 





for systems programming such as BCPL [Ref. 2]. None, however, filled 
the criteria deemed important for this task. Therefore, a new language 
was created, called BLISS (Basic Language for the Implementation of 
Software Systems). 

Zz Design Objectives 

BLISS was designed with several specific goals in mind. The 
goals covered such areas as the absolute requirements of systems pro- 
grams, desirable features for systems programming, and language design. 

The absolute requirements for all systems programs were 
considered to be efficiency, access to all hardware features of the machine, 
and minimal run-time support. 

Those features deemed most important for systems programming 
include modularity, the ability to characterize a variety of data structures 
with diverse representations along with flexibility in the range of control 
structures. 

In considering language design, stress was placed upon the 
requirements for a language which would be easily read, understood, 
and modified. The language would have to provide good documentation, 
be machine dependent, and be useful as a design tool. 

It should be noted that access to all hardware features of 


the machine and machine independence are, clearly, incompatible. 





Therefore, although many of its design objectives were achieved, BLISS 
is decidedly not machine independent. It was specifically designed for 
the PDP-10. 

On Description of BLISS 

Described as a general purpose high~level language for 
writing production software for the PDP-10, BLISS is strictly a modular 
language. Its primary program element is a module which can be separ- 
ately compiled and later linked with other object modules to form a 
complete program. The module consists of one or more executable ex- 
pressions, each of which computes a value. Thus, BLISS can be char- 
@eterized as an “expression language" [Ref. 1]. 

There are many similarities between BLISS and ALGOL or 
PL/I. For example, BLISS is a block structured language with variables 
which obey the usual scope rules. Its expressions are similar in format. 
It provides the usual conditional and looping constructs, Operator 
hierarchy, and potentially recursive procedures. 

Storage is dynamically allocated at block entry and de- 
allocated at block exit for "local" and "register" variables; for "own" 
and "global" variables storage is statically allocated in reserved areas 
of core and remains allocated during execution of the entire program. 
There is, however, no "type" associated with any storage segment 


(a fixed and finite number of 36-bit words), as in ALGOL. 
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Each word or any contiguous set of bits in a word is called 
a "field" and, as such, may be named. The value of a name, however, 
is a "pointer" to, or the address of, that field, as opposed to the familiar 
"contents of" interpretation. 

Since there are no built-in data structures in BLISS, access 
to the "programmer-defined" data structures is through "programmer- 
declared" accessing algorithms. 

The familiar "go to” is replaced by additional control ex- 
pressions to improve readability and structuring of programs. These 
expressions, modified in BLISS-11 (PDP-11 version of BLISS-10) [Ref. 3], 
allow for exiting various control environments such as blocks, compound 
expressions, and looping expressions. 

A time-saving, but space-consuming [Ref. 4] feature is the 
activation of the body of a function or routine as a coroutine and/or 
asynchronous process. 

Highly machine dependent features include the ability to 
insert machine language instructions inline with the other expressions. 

4. Importance of the Implementation of BLISS 

BLISS adds some interesting new concepts to the field of 

programming languages. In addition, the ease with which it can be read 


and understood facilitates redesign or restructuring. 


ie 





BLISS has been proven to be useful as a design tool. For 
example, it has been used to write such systems as a WATFOR-like fast 
FORTRAN compiler and a SIMULA-like event-based simulation system 
eet. 1). 

It seems apparent that if BLISS were implemented on other 
computer systems, programming tasks would be accomplished much more 


efficiently with lower overhead costs in time and effort. 


B. OBJECTIVES 

The overall goal of this project is to design and implement a BLISS 
compiler for the IBM S/360. The first step, however, in reaching this 
goal is the redesign of the language. Thus, the objective of this thesis 
is to tailor or redesign the BLISS language for implementation onthe IBM 
S/360 without greatly compromising the original design. (Reference 5 


presents further work toward the achievement of the overall goal.) 
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II. DESIGN APPROACH 


In redesigning a machine dependent language for implementation 
on another computer, it is imperative to understand the architecture of 
both computers in order to determine those aspects of the language which 
will have to be modified. In addition, it is important to be familiar with 
the particular technique which will be used to implement the language. 
The following sections discuss the approach taken in the implementation 


of the BLISS-360 language. 


A. EVALUATION OF MACHINE DEPENDENCIES 
The purpose of this section is to present a comparison of the per- 
tinent features of the PDP-10 and the IBM S/360 and to discuss the effect 
of their differences on BLISS. (Detailed information concerning the archi- 
tecture of the PDP-10 and the IBM S/360 is given in Refs. 6 and 7, 
respectively.) 
1 Characteristics of the Computers 
This section provides a comparison of the hardware capa- 
bilities of the PDP-10 and IBM S/360 computers. 
The following are the significant features of the PDP-10. 
There are sixteen general registers which can function as accumulators 
Or index registers. In addition, these registers can be referenced as 
The basic addressable unit is 


normal memory locations 0, through 17 


8 8° 
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the word which consists of 36 bits. The following data types are available: 
fixed-point numbers, floating-point numbers, logical operands, and the 
byte - any contiguous set of bits within a word. 

The instruction set on the PDP-10 consists of fixed and 
floating-point instructions as well as a set of five byte manipulation 
instructions. There are two primary types of instruction formats - the 
basic format and the in-out format. In addition, the PDP-10 provides 
another format called the Byte Pointer as the pointer to, or location of, 

a byte to be manipulated. These formats are shown in Figure 1. Note 
that "address type" refers to the type of addressing to be performed, i.e., 
direct or indirect. 

Following are a number of significant features of the IBM 
S/360. There are sixteen general registers which can be used as accumu- 
lators for fixed-point arithmetic, relocation registers, index registers, 
and for logical operations. In addition, there are four floating-point 
Pee tare: for floating-point operations. The basic addressable unit is 
the 8-bit byte. Other addressable units include the halfword, word, 
and the doubleword. It must be noted that since the fixed-length fields, 
i.e., the halfword, word, and doubleword, can be addressed, they must 
be located on an integral boundary in main storage. A halfword, for 
example, must have an address which is a multiple of two. Variable- 


length fields, however, may Start at any byte address. 
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PDP-10 INSTRUCTION FORMATS 
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The data types which are available on the IBM S/360 include 
the character (byte), fixed-point numbers, floating-poing numbers (single 
and double precision), decimal numbers, and logical operands. 

The instruction set consists of fixed and floating-point in- 
structions and an extensive set of byte manipulation instructions. There 
are five basic instruction formats including register-to-register operation 
(RR format), register-and-indexed storage operation (RX format), register- 
and-storage operation (RS format), storage-and-immediate operand 
Operation (SI format), and storage-to-storage operation (SS format). These 
formats are shown in Figure 2. 

Dag Effects of the Machine Differences on BLISS 

Examination of the differences between the PDP-10 and the 
IBM S/360 computers indicates that several modifications are required to 
the BLISS language in order to incorporate such features as machine 
language declarations, “contents of" operators, and pointer parameters. 
In addition, in order to take advantage of the architecture of the IBM 
S/360, additional language constructs for the arithmetic expressions 


and modifications to the allocation declarations are required. 


Be TECHNIQUE USEDSIN THE IMPLEMENTATION OF THE LANGUAGE 
The technique to be used for writing a compiler is of primary con- 
cern in the implementation of a language. For example, the compiler 


could be initially written in assembly language for a small subset of 
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IBM 8/360 INSTRUCTION FORMATS 
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BLISS. Subsequent steps would include rewriting the compiler in the 
language itself with successive extensions implementing desired features 
of the language. 

The technique used in the initial stages of the implementation of 
BLISS-360 is a Translator Writing System (TWS). The following sections 
provide an overview of the TWS used - McKeeman's XPL Compiler Gener- 
ater System [Ref. 8]. 


le The XPL System 

The XPL System was Specifically designed as a tool for writing 
compilers for the IBM S/3 60. The components of the XPL System are dis- 
cussed in this section. 

The XPL System consists of three principal components which 
are expressed in the XPL language (a dialect of PL/I). These components 
are the Analyzer, which analyzes a source language syntactically defined 
in BNF and generates parsing tables; the Skeleton, which performs a 
syntax analysis of a program written in the source language; and XCOM, 
which translates XPL to S/36C machine code. Only the details of the 
Analyzer component are given below. 

fas The Analyzer Component of the XPL System 

The Analyzer component is concerned with the analysis of 

the grammar of a source language. This section provides a general dis- 


cussion of the method it uses to perform this function. 
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The Analyzer reads a phrase-structure grammar expressed in 
Backus-Naur Form (BNF) and determines its acceptability to the Mixed- 
Strategy Precedence (MSP) parsing algorithm. The method used in deter- 
mining the acceptability of the grammar follows. Initially, the grammar is 
checked for certain forms of ambiguities, i.e., it is checked to determine 
whether there exists a sentence in the grammar for which there is no 
unique canonical parse. The stacking decision function (C1) is then 
computed. The purpose of this function is to decide whether the next 
input symbol should be placed on the parse stack or whether the symbols 
in the parse stack should be reduced. The MSP algorithm uses a Cl 
mimetion of degree (1,1) first, i.e., it looks at one symbol on top of the 
stack and one in the input text. In cases where the (1,1) predicate is 
undefined (no voce can be ae mile vertsuto degree (2,1), 1.64, 
two symbols on top of the stack are examined. When all stacking decision 
conflicts are resolved, the production selection function (C2) is computed. 
This function checks the context for equal or embedded right parts and 
determines the correct production to be selected. The MSP algorithm uses 
eme2Z function of degree (1,1), i.e., the correct production must be chosen 
by using no more than one symbol below the production in the parse stack 
along with the next symbol in the input text. 

After the grammar is determined to be acceptable to the MSP 
algorithm, the Analyzer produces tables, such as the stacking tables 
and the context checking tables, to be used for the analysis algorithm 


of the Skeleton component. 
19 





One The Use of Analyzer in the Implementation of BLISS-360 


The Analyzer will accept grammars consisting of a maximum 
of 255 productions. The BLISS-360 language currently consists of 238 
productions; therefore, it can be accepted by Analyzer. It should be noted, 
however, that in the event more than 17 additional constructs are added 
to the language, the data-packing procedures in Analyzer will have to be 
re-written. The alternative solution to this would be the segmentation of 
the grammar allowing several passes in the syntax analysis. This form 
of grammar analysis was considered in the initial design stages and de- 
termined to be not feasible because of the extent of self-embedding in the 
language. 

Although BLISS-360 can be accepted by Analyzer by virtue of 
its size, Analyzer ee a large number of tables for the language. 
Therefore, it was necessary to increase the limits built into Analyzer 


on the size of several tables. 
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(ite RESULTS 


Upon evaluation of the design considerations presented in the 
previous section, several modifications were required to BLISS-10 in 
order to implement the language on the IBM S$/360. This section discusses 
these modifications and provides a general description of the resultant 
language, BLISS-360. In addition, the features to be incorporated in the 
future version of BLISS-360 will be described. 

A. MO@MMIGATIONS TO THE ANALYZER COMPONENT OF THE XPL 

SYSTEM : 

BLISS is a large language full of self-embedded structures. There- 
fore, in order to make the language acceptable to the Analyzer component 
of the XPL System, several modifications were made to Analyzer. These 
changes are listed in Table I. It should be noted that the value of those 
parameters not reflected in the output listing from Analyzer are left blank 
in the table. 

As a result of these changes, the Analyzer program requires a 


region of 250 K bytes in which to perform the grammar analysis. 


Be DESCRIPTION OF THE LANGUAGE BLISS-360 
BLISS 360 is most easily described by referring to similar con- 
structions in BLISS-10 since BLISS-360 is intended to perform the same 


tasks for the IBM S/360 as BLISS-10 does for the PDP-10. 


ot 





TABLE I 


MODIFICATIONS TO ANALYZER 





















Parameter Use Original Version |Modified Version | Size 
of Analyzer of Analyzer Required 
by 
BLISS-360 | 
ea aR (ES 
Depth Level of Zo5 t023 816 
recursion 
Maxnfll Maximum number 5000 30000 275136 
of contexts 
for each 
rightmost non- 
terminal in 
all the 
canonical 
sentential 
forms 
axntrip Maximum number 1000 4000 553 











Maximum number 250 Smal - 
of symbols in 
the input 


string 


extlimit 
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Maximum number 
of contexts 

for which Cl 

ana C2 are 
undefined 


Maxtrouble 





on 
(=) 





As is evident from the complete BNF description of the current 
version of BLISS-360 in Appendix A, most of the richness of BLISS-10 
has been retained. However, there are fundamental differences between 
the two languages. It is the purpose of this section to discuss the dif- 
ferences between BLISS-10 and the current version of BLISS-360. 

In Order to more fully understand BLISS-360 and the following dis- 
cussion, it is recommended that the reader familiarize himself with 
BLISS-10 [Ref. 9]. 

BLISS-10 provides the ability to control the actions of the compiler 
with respect to the program through the use of the "parameters" field in 
the module definition and in the "switches" declaration. This capability 
will be provided, but is not reflected in the syntax. 

In BLISS-10, the reserved word SEMICOLON indicates that side 
effects could occur in the previous expression; thus, any code optimi- 
zation must take this into account. SEMICOLON is, however, syntactically 
identical a the symbol ";" and is not included in the BLISS-360 description. 

The literal construct has been modified to include "identifier" which 
replaces "name" in all relevant constructs. The symbol "identifier" in 
BLISS-360 is syntactically and semantically identical to "name" in 
BLISS-10. It should be noted that the symbols comprising the "literal" 
construct are used as terminal symbols to be recognized by the Scan 


Routine in the Skeleton by their use. Another symbol, "string," is used 


2s 





Similarly. Note that the "plit" construct is not included in the current 


version of BLISS-360. 
The symbol "number" in BLISS-360 differs both in syntax and 
semantics from "number" in BLISS-10. In BLISS-360, "number" is 


syntactically defined by the following BNF notation: 


<Number> :: = <Fixed point > | < Floating point > < Packed decimal > 
menceadspoint Ss : : = <Fullword > | £Halfword > 
ai ullwerdy> > + = < Decimal number > | ¢< Hexadecimal number > 


< Decimal number> ::= #£<Digit> | <Decimal number > < Digit > 


~< Hexadecimal number> ::= # < Hex digit > | 


< Hexadecimal number > < Hex digit > 


< Haliword> ::= < Decimal number > H 

wat loatimg point > +; = < Long real > | ¢< Short real > 
@ilonguweal 7 2: = <Short real> LL 

eoertreal > +: — < Decimal number > 





< Short real > < Decimal number > | 


¢ Short real > < Exponent > 











Aieepement > 9 +: — FE £ <@ Decimal number > | E- Decimal number > 
< Packed decimal> ::= <Decimal number> P 

Digit > 2 =i] 1 2 3| 4 | 6 q a| s 

<Hexdigit > ~: : = <pigit>| |p fc |p |e] 
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Several examples are provided to illustrate the various types of 
numbers described: 

123H #1D Hiei! oelamasile Done 1) 4096P 

The number 123H represents the integer constant 123 requiring one 
halfword of storage, while the number #1D represents the hexadecimal 
equivalent of the integer constant 29 requiring one fullword of storage. 
The number 787.8E+9L represents the long real (double precision) floating- 
point number 787.8 x he the number 59.E-10 represents the short real 
(single precision) floating-point number 59.0 x oe and 4096P represents 
the integer constant 4096 in packed decimal format requiring three bytes 
of storage. 

Because the PDP-10 provides the capability of addressing any con- 
tiguous field in a memory word, BLISS-10 allows left and right justification 
of character strings, denoted by single and double quotes, respectively. 
The strings are limited in size to the number of characters which can be 
represented in a word. The size is dependent upon the type of code used 
to specify the characters. (The PDP-10 computer uses 7-bit ASCII, 6-bit 
ASCII (SIXBIT), and RADIX-5S0 codes.) 

The byte, the smallest addressable unit on the IBM S/360, repre- 
sents one character in the character string. Consequently, BLISS-360 
does not allow for left and right justification in strings and only allows 
single quotes to be used to enclose the string. The number of characters 


in the string is not limited to the word size. It should be noted that 


ZS 





although hardware is available to process 8-bit ASCII codes, the EBCDIC 
coding scheme is primarily used on the IBM 8/360. Therefore, only 
EBCDIC strings are allowed in BLISS-360. 

BLISS-10 allows the inclusion of an "escape to control" character, 
represented by the symbol "?" in a string. For example, "?M" is inter- 


preted as "control-M," or carriage-return. Since this control character 
only has meaning for the PDP-10, the symbol '"?" in a BLISS-360 string 
will have no special meaning. A double quote within a string is taken 
as a Single quote. 

Another feature of BLISS-10 utilizing the hardware capabilities of 
the PDP-10 is the "pointer parameter" construct. A'pointer parameter" 
is the address of a field of a contiguous number of ae within a word 
(byte). It Bees. 6: five parameters on the PDP-10 which are encoded 
into a single word - the Byte Pointer shown in Figure 1. The usefulness 
of the "pointer parameter" is readily apparent; it allows access to, and 
manipulation of, a particular byte within a word. Since the IBM S/360 
does not have the equivalent of the Byte Pointer, it will be necessary to 
implement the "pointer parameter" through subroutine calls or sequences 
of shift and mask operations. This construct, however, is not included 
in the present BLISS-360 grammar. 

There are three "contents of" operators in BLISS-10: the dot, the 
"@" operator, and the " i Operator. When these operators are used with 


an identifier, they allow direct access to, and control over, fields 
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within words and pointers to fields stored in memory. Only the dot, 
representing the value of the identifier, is defined in BLISS-360. The size 
of the value is dependent upon the boundary alignment of the identifier. 
For example, if an identifier is aligned on a halfword boundary, then the 
value obtained will be 16-bits in length. Since the value of the entire 
address is fetched, the "@" and the " \o operators would be redundant 

Mie Siioo—3 00 . 

Several formats are provided in BLISS-360 to resolve the "dangling 
else" problem of the conditional expressions in BLISS-10. Similar to the 
format proposed by McKeeman in Ref. 8, the BLISS-360 constructs always 
associate the ELSE with the closest unmatched IF-THEN. 

The BLISS-10 increment and decrement Pessions which are 
similar to the ALGOL FOR statement [Ref. 10] allow for the omission of 
any of the phrases "FROM Ey olor or bY be. BLinog—300 only 


Z 3 


provides for the omission of the "BY EA phrase. The default value "BY 1" 
is supplied in the event this phrase is omitted. 

The familiar "go to” expression is not allowed in the BLISS-10 
language. Instead, BLISS-10 provides an "escape" expression as the 
form for exiting control environments such as the block. The "escape” 
expression consists of a wide variety of exit expressions such as 


EXITBLOCK. Each exit expression causes control to leave one or more 


of the specific control environments in which the exit expression is 


at 





embedded and pass onto the next expression following the outermost 
environment exited. 

In order to reduce the number of exit expressions, BLISS-11 was 
designed with a "leave" expression replacing all exit expressions 
[Ref. 3]. The "leave" expression functions the same way as the "escape" 
expressions. The difference between the two, however, is that the con- 
trol environment to be exited is not specified by the particular exit expres- 
sion used; instead, it is identified by the name which points to the 
location in the program in which it occurs. In other words, the control 
environment is labelled. 

The BLISS-360 language modified the syntax of BLISS-10 for the 
“escape" expression allowing only the EXITLOOP and RETURN expressions 
from BLISS-10 and adding the eee expression from BLISS-1ll. The 
syntax for the BLISS-360 "escape" expression follows: 

< Escape expression > ::= < Environment escape > | 
< Procedure escape > 

< Environment escape > ::= < Loop escape > | 
< Control environment escape > 


Meooprescape 7 | } +s Exit >) |< Exit expression > 





Zo Exit > 2 >= EXITEOOP 
“en -ciexpressiom 2: : = EXITLOOP < Exit end > 
oeratcend. > +: = <_Braced E > | <Escape value > 


< Braced E > < Escape value > 
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< Braced E> ::= SE > 


~ Escape value> ::= << With clause > 
< With clause > ::= WITH < Unlabelled expr > 
< Control environment escape > ::= < Labelled leave > 


¢ Labelled leave > < Escape value > 


< Labelled leave > ::= LEAVE < Identifier > 

< Procedure escape > ::= g¢ Return > | <Return expression > 
conetum > ?: = RETURN 

< Return expression > ::= RETURN < Escape value > 


Although the syntax of the EXITLOOP and RETURN expressions 
has been modified, the semantics remain the same. 

The "leave" expression terminates the anata control environment 
in which the "leave" expression is embedded. The value of the "leave" 
expression is that obtained by evaluating the “escape value." If the 
“escape value" is omitted, the value of the "leave" expression is zero. 

An example of the use of the "leave" expression is provided: 

WHILE .A NEO .B DO 

PACE Mb elie Guin oY.oL THEN LEAVE LABELIT WITH .B 
Hibben: = Age B/2 

In conjunction with the "leave" expression, the BLISS-360 
language provides a "label" declaration and a modified syntactical 
description of"expression." The "label" declaration is syntactically 


defined as: 





< Label declaration > ::= < Label head > < Identifier > 
@tabel head > <<: = LABEL < Label head > < Identifier > , 

The "label" declaration is similar, in only one respect, to the 
forward function declaration in that it names the identifiers to be used 
as labels later in the block in which the declaration occurs. 

Example: 

PARE EL UABELIT, LABELT, LABELZ 

The"expression'in BLISS-360 allows for both labelled and unlabelled 

expressions. Itis defined by the following BNF: 
Zeb > ::= < Labelled expr > < Unlabelled expr > 
< Labelled expr > ::= < Label > : < Unlabelled expr> 

It should be noted that "label" must have been previously declared 
by a "label" declaration. The unlabelled expression is exactly equivalent 
to"expression’as defined in BLISS-10. 

In order to avoid conflicts in parsing BLISS-360 programs, several 
reserved words in the allocation declaration were changed. The changes 
are listed in Table II. 

It should be noted that since the general-purpose and floating- 
point registers on the IBM S/360 cannot be referenced as memory locations, 
storage segments for the REGALLOC, FPREGALLOC, REGISTER, and 
FPREGISTER variables will be the same as for the LOCAL Panes in 


Bilso-10% 
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BLISS-360 incorporated the BLISS-10 feature of allowing the insertion 
of machine language instructions into the BLISS program. However, 
because of the variety of instruction formats used by the IBM S/360, the 
formats of the machine language declaration and the inline code are 
modified. 

The form to be followed for the machine language declaration in 
BLISS-360 will resemble the "function" declaration of PL360 [Ref. 11]. 
An example of the BLISS-360 machine language declaration is: 

MACHOP MVC = (5, #D200) 
where MVC is the mnemonic name of the operation code, the number "5" 
defines the format of the instruction, and the hexadecimal number "D200" 
defines the first two bytes of the instruction. Note that "D2" is the 
hexadecimal equivalent of the operation code MVC. 

The format to be followed for the inline coding of machine language 
instructions is the same as the format used for the "function" statements 
in PL360. 

An example of inline code in BLISS-360 follows: 

MvVG  (l0> Fieldi, Field2) 
where the number "10" specifies the length of the receiving field, 
"Field1" provides the location of the receiving field, and "Field2" pro- 


vides the location of the sending field. 
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TABLE Il 


BUipoesoUaCHANGES TO RESERVED WORDS 
IN THE ALLOCATION DECLARATION 


Reserved Word Reserved Word 
in BLISS-10 Declaration in which used in BLISS-360 | 





REGISTER Register allocation declaration REGALLOC 


EXTERNAL External allocation declaration EXTALLO CG 

.- Floating-point register F PREGALLOG 
allocation declaration 

REGISTER Alternate register REGISTER 
allocation declaration 


Alternate floating-point EPREGISTER 
register allocation declaration 








Several symbols used in BLISS-10 are not available for use in 
BLISS-360. Table III contains a listing of the symbols replaced in 
Buiso—360. 

Finally, note that BLISS-360 programs must contain the reserved 


word "EOF" signalling the end of the program. 
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TABLE U1 


SYMBOLS REPLACED IN BLISS-360 
















Symbol used Equivalent symbol | 
— BLISS-10 —— in BLISS-360 





Use 






Delimiter for "structure 
access sand “Structure 
declaration. 


a 
ee 
ase 
a 
i,;i»z>n»= rr 


ce. FUTURE DEVELOPMENTS IN THE DESIGN OF BLISS-360 








To complete the design phase of the BLISS-360 language, several 
additions and modifications will be required. The changes discussed in 
this section will allow BLISS-360 to fully utilize the hardware capabilities 
of the IBM S/360. In addition, they will provide BLISS-360 with all the 
richness of BLISS-10. 

In order to provide flexibility in the types of arithmetic operations 
to be performed in the BLISS-360 program without resorting to inline 
coding of machine language instructions, the "P5" and "P6" constructs 


will be modified as follows: 
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< P6> .:= <P5> | <Neg > <Ps> | 2h ect PS 


Oe ee ae > KPO > 








~Neg> ::= NEG | FNEG | PNEG 

{+> ::= + | aps| app | apt | ans 

Me i Se | suBH | SUBP suBL | SUBS 

Ceo i = < P4> | any tue * Oy PA > | eS 7 ne 4a 
Z£P5> MOD <P4> 

La MULH | MULP | MULL | MULS 

<2: - / | DIVP DIV | DIVS 








The "NEG" construct provides fixed-point, floating-point, and 
packed decimal "negative" Operations. The other types of arithmetic 
Operations are defined by the symbol or the final letter of the reserved 
word as follows: eee eee is specified by "H"; packed 
decimal is denoted by "P"; single precision (short) floating-point is 
specified by "S"; and double precision (long) floating-point is denoted 
by “Do All other operations are fullword. 

Since storage is only allocated by words in the PDP-10, there 
are no addressing problems in BLISS-10. Storage can be allocated in 
several ways on the IBM S/360, as previously mentioned. Therefore, 
BLISS-360 must provide the capability of specifying the alignment of the 
variables when storage is allocated. Table IV lists the reserved words 
which will be used in the allocation of storage and their corresponding 
boundary alignment. 
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TABLE IV 


LIST OF RESERVED WORDS INDICATING BOUNDARY ALIGNMENT 


Type of Variable Boundary Alignment 
Byte 
Halfword 


Halfword 
Halfword 
Fullword 
Fullword 
Fullword 
Fullword 
Fullword 
Doubleword 
Doubleword 
Doubleword 
Doubleword 


Doubleword 
















The IBM S/360 instruction set contains an extensive number of 
byte manipulation instructions. It may be desirable, however, to have 
the capability of manipulating characters without resorting to inline 
machine language coding. This can be provided by incorporating a modi- 
fied version of the BLISS-10 "pointer parameter" into BLISS-360. The 
BLISS-360 version of the"pointer parameter ," called the Bit/Byte Modifier, 
will provide the capability of accessing a field consisting of a contiguous 


number of bits, or bytes. It will have the general format of : 


35 





Jeger 
- < 2 2 3 y, 
where EY is the base address, Ey indicates the modifier type (0 indicates 


Byte access; 1 indicates Bit access), E, is the starting position, and E. 


z 


is the size of the field. In addition, E, and Ey may be optionally omitted 
in which case the default values of 0 and 1, respectively, will be assigned. 
It should be noted that the format of the Bit/Byte Modifier can only 
be viewed as a guideline for future implementation because use of the symbols 
eo ecnd.- 7 “sor parenthesis as delimiters will cause conflicts with 
the "structure access" and "function call" constructs. 
Examples of the Bit/Byte Modifier will illustrate its use. Assume 
the variables SEND and RECEIVE are aligned on doubleword boundaries, 
with default structure Vector and size one (doubleword). 
RECEIVE := .oEND 
PE@EIVE: = .cSEND <0,0,8 > 
In both cases, the entire value of send is stored into RECEIVE. 
RECEIVE. — SEND <0,4,2 > 
In this case, only the value of the field containing the fifth and 
sixth bytes is stored into RECEIVE. 
Finally, the "plit" construct must be incorporated into the grammar. 
Thus, although all siege constructions do not appear in the 
present BLISS-360 grammar, sufficient constructs exist to allow compiler 


development to continue while the grammar is extended as a separate 


effort. 
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Ive GONCLUSIONS 


A system software production language, called BLISS-360, was 
designed for the IBM S/360 computer. As a modification of the PDP-10 
“implementation language" BLISS-10, BLISS-360 is similar in construction. 
However, it differs from BLISS-10 in those constructs relevant to the 
hardware capabilities of the host computer. 

The design of BLISS-360 is based upon the production of a compiler 
using the XPL Compiler Generator System. The complete design of the 
language, including the future additions described, will provide BLISS-360 
with all the capabilities of BLISS-10 and will permit it to take full advantage 
of the architecture of the IBM S/360. Thus, the BLISS-360 language pro- 


vides the foundation for future development of a BLISS-360 compiler. 
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